Не так давно мы просили вас ответить на 4 небольших вопроса о миграции на VMware vSphere 5 и используемых хранилищах и гипервизорах. Рады представить вам результаты этого опроса.

1. Оказывается, что большинство из опрошенных уже использует VMware vSphere 5, хотя количество пользователей 4-й версии тоже не так уж и мало:

2. В течение 3-6 месяцев на vSphere 5 перейдет большинство пользователей:

3. В плане хранилищ вперед вырываются агрессивные хапэшники:

Отметим большой потенциал продаж хранилищ под виртуализацию .

4. Несмотря на то, что нас читают в основном пользователи VMware, платформу VMware vSphere используют чуть больше половины опрошенных:

Отметим, что Parallels и Red Hat - использует 3 человека из опрошенных. Подозреваю, что это одни и те же люди :) Шучу.

Напомним, что совсем недавно компания «Код Безопасности» выпустила технический релиз новой версии vGate R2 с поддержкой VMware 5. Сейчас она проходит инспекционный контроль во ФСТЭК для получения соответствующих сертфикатов, наличие которых позволит вашей организации пройти процедуру аттестации или проверки со стороны государственных органов. Сегодня мы более подробно расскажем о новых политиках настройки безопасной среды виртуализации.

Интересное решение попалось на глаза - HotLink SuperVISOR for VMware, продукт, позволяющий в консоли vSphere Client объединить управление платформами и виртуальными машинами VMware vSphere, Microsoft Hyper-V и Citrix XenServer (+KVM от Red Hat). Данное решение позиционируется как комбинированное средство управления гетерогенной инфраструктурой виртуализации:

Работает HotLink SuperVISOR как плагин к vSphere Client, где вы можете увидеть центры управления для гипервизоров гетерогенной среды:

Поскольку Microsoft Hyper-V сейчас набирает обороты, и его присутствие в виртуальной инфраструктуре многих компаний доходит до 25%, подобные решения становятся весьма востребованными, особенно на фоне того, что VMware напрочь отказывается от интеграции своего vCenter со сторонними гипервизорами по очевидным причинам.

Обещают, что продукт HotLink обладает следующими возможностями по гетерогенному управлению по сравнению с другими моделями администрирования:

Практическую демонстрацию продукта SuperVISOR можно увидеть на видео ниже:

Из сайта я не смог понять, когда будет доступно решение HotLink, но сама идея выглядит очень заманчиво и перспективно.

Кстати, помните мы проводили исследование по миграции на vSphere 5? Пройдите, пожалуйста, кто не прошел - очень интересны результаты (сейчас пока 124 человека). Там всего 4 небольших вопроса. Спасибо.

Многие из вас уже читали о новой версии StarWind Enterprise 5.8 для организации отказоустойчивых ISCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Одна из интересных фич новой версии - возможность резервного копирования хранилищ виртуальных машин, идущая как плагин к продукту (VM Backup). Бэкап работает как для vSphere, так и для Hyper-V (с поддержкой дедупликации).

В связи в этим обновилось сравнение изданий продукта для платформ VMware и Microsoft.

Издания StarWind iSCSI SAN (для серверов ESX / ESXi):

Возможности	StarWind Enterprise CDP Edition	StarWind iSCSI SAN
		1TB	2TB	4TB	8TB	16TB	Unlimited
Support	1 year	1 year	1 year	1 year	1 year	1 year	1 year
# of Servers per license	1	2	2	2	2	4 (2 HA sets)	4 (2 HA sets)
Maximum Capacity	Unlimited	1TB	2TB	4TB	8TB	16TB	Unlimited
# of Concurrent iSCSI Connections	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Ethernet ports	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Served Disk Drives	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option	$399.00*	$399.00*	$399.00*	$399.00*	$399.00*	$399.00*	$399.00*

Издания StarWind Native SAN for Hyper-V:

Возможности	StarWind Native SAN for Hyper-V
	1TB	2TB	4TB	8TB	16TB	Unlimited
Support	1 year	1 year	1 year	1 year	1 year	1 year
# of Servers per license	2	2	2	2	2	2
Maximum Capacity	1TB	2TB	4TB	8TB	16TB	Unlimited
# of Concurrent iSCSI Connections	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Ethernet ports	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Served Disk Drives	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Synchronous Mirroring (Active-Active High Availability)
Remote Replication (Active-Passive)
Automatic Failover
Failback with Fast Synchronization
Disk Bridge
SPTI
Image File
IPSec, CHAP, ACL, iSNS
CDP / Snapshots
Thin Provisioning
High Speed Caching
Event Log
Event notifications
Deduplication
*VM Backup Option	$399.00*	$399.00*	$399.00*	$399.00*	$399.00*	$399.00*

Стоимость VM Backup Option указана за физический сервер ESX или Hyper-V, виртуальные машины которого вы планируете бэкапить. При этом неважно количество процессоров и ВМ на данном сервере.

Как знают многие пользователи VMware, в новой версии платформы VMware vSphere 5 появилась возможность производить "горячую" миграцию виртуальных машин между хостами ESXi сразу по нескольким физическим сетевым адаптерам (Multi NIC vMotion). Опишем кратко особенности использования данной технологии.

При миграции ВМ в vSphere 5 есть следующие особенности:

• Поддержка до четырех одновременных миграций на адаптерах 1Gbps и до 8 одновременных миграций по 10Gbps сетевым адаптерам.
• Поддержка на хосте ESXi до 4 адаптеров 10Gbps и до 16 адаптеров 1Gbps.
• Миграция одной виртуальной машины vMotion может идти сразу по нескольким сетевым адаптерам (между ними просиходит балансировка нагрузки)
• В целом, vMotion стала работать быстрее (в подавляющем большинстве случаев, время переключения - не более 1 секунды)
• Логи ошибок vMotion стали богаче и информативнее

Миграция vMotion по нескольким сетевым адаптерам - это комплексный процесс, поскольку vSphere приходится обрабатывать различные комбинации из 1 GbE и 10 GbE адаптеров на хостах.

Перед началом vMotion сервер vCenter анализирует сетевые адаптеры на хостах VMware ESX / ESXi и определяет суммарную пропускную способность, которая доступна для миграции. Например, если у хоста 2 адаптера 1GbE и 1 адаптер 10GbE, тогда пул хоста считается равным 12 GbE. Емкость пула определяется как на исходном, так и на целевом хосте.

Далее есть несколько аспектов работы vMotion:

• Если исходный и целевой хосты имеют адаптеры 1GbE NIC, то между ними настраивается одно соединение для vMotion.
• Если исходный хост имеет 3 адаптера 1GbE NIC, а целевой хост имеет 1 адаптер 10GbE, то с исходного хоста к целевому, в его адаптер, открывается 3 параллельно работающих соединения (сокета vMotion).
• Если исходный хост имеет 15 адаптеров 1GbE, а целевой - 1 адаптер 10GbE и 5 адаптеров 1GbE, то первые 10 адаптеров исходного хоста соединяются с одним 10GbE-адаптером целевого, а дальше 5 адаптеров 1GbE соединяются на исходном и целевом хостах между собой. Таким образом, для миграций (одной или нескольких) открыто суммарно 15 соединений.
• Ну и, само собой, если на исходном хосте 2 адаптера 1GbE, а на целевом только один такой адаптер, то будет открыто только одно соединение 1GbE.

При всех этих моментах нужно помнить про ограничения из первого списка. Ну и напоследок видео про настройку vMotion по нескольким сетевым адаптерам:

И еще одно видео с комментариями EMC:

Наконец-то Forbes Guthrie выпустил самую известную "шпаргалку" по администрированию платформы VMware vSphere 5 - Reference Card. На этом плакате A4 из двух страниц собраны самые нужные команды и теоретическая информация для администраторов VMware, касающаяся хостов ESXi, сервера управления vCenter, виртуальных машин, хранилищ, сетей и т.п.:

Этот документ может оказаться очень полезным при подготовке к экзамену на сертификацию VMware Certified Professional 5 (VCP5). Кстати о VCP5 - для тех, кто имеет сертификат VCP4, осталось совсем немного времени для сдачи экзамена без прохождения курса VMware vSphere: What's New [V5.0] (за немалые деньги, кстати). А именно - сдать нужно до 29 февраля.

В данной статье объединены все общедоступные на сегодняшний день расширенные настройки кластера VMware HA (с учетом нововведений механизма) для обеспечения высокой доступности сервисов в виртуальных машинах VMware vSphere 5.0 и более ранних версий. Отказоустойчивость достигается двумя способами: средствами VMware HA на уровне хостов ESXi (на случай отказов оборудования или гипервизора) и средствами VMware VM Monitoring (зависание гостевой операционной системы).

На каждом хосте службой VMware HA устанавливается агент Fault Domain Manager (FDM), который пришел на смену агентам Legato AAM (Automated Availability Manager). В процессе настройки кластера HA один из агентов выбирается как Master, все остальные выполняют роль Slaves (мастер координирует операции по восстановлению, а в случае его отказа выбирается новый мастер). Теперь больше нет primary/secondary узлов. Одно из существенных изменений VMware HA - это Datastore Heartbeating, механизм, позволяющий мастер-серверу определять состояния хост-серверов VMware ESXi, изолированных от сети, но продолжающих работу с хранилищами.

Задать Advanced Options для VMware HA (иногда их называют Advanced Settings) можно, нажав правой кнопкой на кластер в vSphere Client и далее выбрав пункт "Edit Settings", где уже нужно вводить их как указано на картинке:

Список Advanced Options для VMware HA, действующих только в vSphere 5.0:

• das.ignoreinsufficienthbdatastore - определяет, будет ли игнорировано сообщение о количестве имеющихся Heartbeat-хранилищ, которое меньше сконфигурированного в настройке das.heartbeatdsperhost (по умолчанию - это 2 хранилища). То есть если Heartbeat-хранилище присутствует только одно - будет выведено следующее сообщение:
  
  Выставление значения этого параметра в true уберет это предупреждение из vSphere Client.
• das.heartbeatdsperhost - определяет количество Heartbeat-хранилищ, которое можно регулировать данной настройкой (допустимые значения - от 2 до 5). По умолчанию, данное значение равно 2.
• das.config.log.maxFileNum - определяет количество лог-файлов, в пределах которого будет происходить их ротация.
• das.config.log.maxFileSize - максимальный размер лог-файла, задаваемый в байтах.
• das.config.log.directory - путь для хранения лог-файлов VMware HA. При задании настроек логов следует руководствоваться следующей таблицей (подробнее читайте тут на последних страницах):
  
• das.config.fdm.deadIcmpPingInterval - интервал между пингами по протоколу ICMP для определения доступности Slave-хоста ESXi в сети со стороны Master, в случае, если нет коммуникации с FDM-агентом Slave-хоста (используется, чтобы определить - сломался агент FDM или хост вышел из строя). По умолчанию задано значение 10 (секунд).
• das.config.fdm.icmpPingTimeout - таймаут, который хост (мастер) ожидает перед получением ответа на пинг, при неполучении которого он считает один из хостов недоступным из сети (то есть время, которое он дает для ответа на пинг, после чего начинаются операции по восстановлению ВМ). По умолчанию задано значение 5 (секунд).
• das.config.fdm.hostTimeout - таймаут, который мастер ожидает после события неполученного хартбита от FDM-агента хоста после чего он определяет является ли хост отказавшим (dead), изолированным (isolated) или в другом сегменте разделенной сети (partitioned). По умолчанию задано значение 10 (секунд). Сами же хартбиты между мастером и slave-хостами посылаются каждую секунду.
• das.config.fdm.stateLogInterval - частота записи состояния кластера в лог-файл. По умолчанию выставлено в 600 (секунд).
• das.config.fdm.ft.cleanupTimeout - когда сервер vCenter инициирует запуск Secondary-машины, защищенной с помощью Fault Tolerance, он информирует мастера HA о том, что он начал этот процесс. Далее мастер ждет время, выставленное в этой настройке, и определяет запустилась ли эта виртуальная машина. Если не запустилась - то он самостоятельно инициирует ее повторный запуск. Такая ситуация может произойти, когда во время настройки FT вдруг вышел из строя сервер vCenter. По умолчанию задано значение 900 (секунд).
• das.config.fdm.storageVmotionCleanupTimeout - когда механизм Storage vMotion перемещает виртуальную машину с/на хосты ESX 4.1 или более ранней версии, может возникнуть конфликт, когда HA считает, что это не хранилище ВМ переместилось, а сама ВМ отказала. Поэтому данная настройка определяет, сколько времени мастеру нужно подождать, чтобы завершилась операция Storage vMotion, перед принятием решения о перезапуске ВМ. См. также нашу заметку тут. По умолчанию задано значение 900 (секунд).
• das.config.fdm.policy.unknownStateMonitorPeriod - определяет сколько агент мастера ждет отклика от виртуальной машины, перед тем как посчитать ее отказавшей и инициировать процедуру ее перезапуска.
• das.config.fdm.event.maxMasterEvents - определяет количество событий, которые хранит мастер операций HA.
• das.config.fdm.event.maxSlaveEvents - определяет количество событий, которые хранят Slave-хосты HA.

Список Advanced Options для VMware HA в vSphere 5.0 и более ранних версиях:

• das.defaultfailoverhost - сервер VMware ESXi (задается короткое имя), который будет использоваться в первую очередь для запуска виртуальных машин в случае сбоя других ESXi. Если его емкости недостаточно для запуска всех машин – VMware HA будет использовать другие хосты.
• das.isolationaddress[n] - IP-адрес, который используется для определения события изоляции хостов. По умолчанию, это шлюз (Default Gateway) сервисной консоли. Этот хост должен быть постоянно доступен. Если указано значение n, например, das.isolationaddress2, то адрес также используется на проверку события изоляции. Можно указать до десяти таких адресов (диапазон n от 1 до 10).
• das.failuredetectioninterval - значение в миллисекундах, которое отражает время, через которое хосты VMware ESX Server обмениваются хартбитами. По умолчанию равно 1000 (1 секунда).
• das.usedefaultisolationaddress - значение-флаг (true или false, по умолчанию - true), которое говорит о том, использовать ли Default Gateway как isolation address (хост, по которому определяется событие изоляции). Параметр необходимо выставить в значение false, если вы планируете использовать несколько isolation-адресов от das.isolationaddress1 до das.isolationaddress10, чтобы исключить шлюз из хостов, по которым определяется событие изоляции.
• das.powerOffonIsolation - значение флаг (true или false), используемое для перекрытия настройки isolation response. Если установлено как true, то действие «Power Off» - активно, если как false - активно действие «Leave powered On». Неизвестно, работает ли в vSphere 5.0, но в более ранних версиях работало.
• das.vmMemoryMinMB - значение в мегабайтах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше памяти на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МБ.
• das.vmCpuMinMHz - значение в мегагерцах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше ресурсов процессора на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МГц (vSphere 4.1) и 32 МГц (vSphere 5).
• das.conservativeCpuSlot - значение-флаг (true или false), определяющее как VMware HA будет рассчитывать размер слота, влияющего на admission control. По умолчанию установлен параметр false, позволяющий менее жестко подходить к расчетам. Если установлено в значение true – механизм будет работать как в VirtualCenter 2.5.0 и VirtualCenter 2.5.0 Update 1. Неизвестно, осталась ли эта настройка актуальной для vSphere 5.0.
• das.allowVmotionNetworks - значение-флаг, позволяющее или не позволяющее использовать физический адаптер, по которому идет трафик VMotion (VMkernel + VMotion Enabled), для прохождения хартбитов.Используется только для VMware ESXi. По умолчанию этот параметр равен false, и сети VMotion для хартбитов не используются. Если установлен в значение true – VMware HA использует группу портов VMkernel с включенной опцией VMotion.
• das.allowNetwork[n] – имя интерфейса сервисной консоли (например, ServiceConsole2), который будет использоваться для обмена хартбитами. n – номер, который отражает в каком порядке это будет происходить. Важно! - не ошибитесь, НЕ пишите das.allowNetworkS.
• das.isolationShutdownTimeout - значение в секундах, которое используется как таймаут перед срабатыванием насильственного выключения виртуальной машины (power off), если не сработало мягкое выключение из гостевой ОС (shutdown). В случае выставления isolation response как shutdown, VMware HA пытается выключить ее таким образом в течение 300 секунд (значение по умолчанию). Обратите внимание, что значение в секундах, а не в миллисекундах.
• das.ignoreRedundantNetWarning - значение-флаг (true или false, по умолчанию false), который при установке в значение false отключает нотификацию об отсутствии избыточности в сети управления («Host xxx currently has no management network redundancy»). По умолчанию установлено в значение false.

Настройки VM Monitoring для VMware HA платформы vSphere 5.0 и более ранних версий:

• das.vmFailoverEnabled - значение-флаг (true или false). Если установлен в значение true – механизм VMFM включен, если false – выключен. По умолчанию установлено значение false.
• das.FailureInterval - значение в секундах, после которого виртуальная машина считается зависшей и перезагружается, если в течение этого времени не получено хартбитов. По умолчанию установлено значение 30.
• das.minUptime - значение в секундах, отражающее время, которое дается на загрузку виртуальной машины и инициализацию VMware Tools для обмена хартбитами. По умолчанию установлено значение 120.
• das.maxFailures - максимальное число автоматических перезагрузок из-за неполучения хартбитов, допустимое за время, указанное в параметре das.maxFailureWindow. Если значение das.maxFailureWindow равно «-1», то das.maxFailures означает абсолютное число отказов или зависаний ОС, после которого автоматические перезагрузки виртуальной машины прекращаются, и отключается VMFM. По умолчанию равно 3.
• das.maxFailureWindow - значение, отражающее время в секундах, в течение которого рассматривается значение параметра das.maxFailures. По умолчанию равно «-1». Например, установив значение 86400, мы получим, что за сутки (86400 секунд) может произойти 3 перезапуска виртуальной машины по инициативе VMFM. Если перезагрузок будет больше, VMFM отключится. Значение параметра das.maxFailureWindow может быть также равно «-1». В этом случае время рассмотрения числа отказов для отключения VMFM – не ограничено.

Настройки, которые больше не действуют в vSphere 5.0:

• das.failuredetectiontime

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Раньше была настройка das.failuredetectiontime - это значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины. По умолчанию, значение равно 15000 (15 секунд). Рекомендуется увеличить это время до 60000 (60 секунд), если с настройками по умолчанию возникают проблемы в работе VMware HA. Если у вас 2 интерфейса обмена хартбитами - можно оставить 15 секунд.

В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.

Теперь все работает следующим образом (см. также новые das-параметры, которые были описаны выше).

Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):

• Время T0 – обнаружение изоляции хоста (slave).
• T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
• T0+25 сек – Slave сам себя назначает мастером.
• T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Наступление изоляции хост-сервера ESXi, являющегося Master:

• T0 – обнаружение изоляции хоста (master).
• T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. И да, помним, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.

• das.bypassNetCompatCheck

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Это значение-флаг (true или false, по умолчанию false), который будучи установлен в значение true позволяет обойти дополнительную проверку на совместимость с HA. В VirtualCenter Update 2 была введена проверка на совместимость подсетей, по которым ходят хартбиты. Возникала ошибка: «HA agent on in cluster in has an error Incompatible HA Network: Consider using the Advanced Cluster Settings das.allowNetwork to control network usage». Теперь, если сети считаются несовместимыми с точки зрения HA, однако маршрутизируемыми – новая опция поможет осуществить корректную настройку кластера.

Для тех пользователей, кто только начинает свое знакомство с технологиями виртуализации, первым серверным гипервизором в большинстве случаев становится VMware ESXi. В этой статье мы приведем пошаговую инструкцию по получению лицензионного ключа на беcплатную платформу виртуализации VMware ESXi, которая официально называется VMware vSphere Hypervisor.

Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).

Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.

Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).

Для решения проблемы нужно сделать следующее:

1. Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
2. Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
3. Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
4. Будет небольшая задержка на выполнение скрипта.
5. Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.

Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.

Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.

Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии).

Если у вас в инфраструктуре несколько версий VMware vSphere (например, 4.1 и 5.0) или вы хотите поставить VMware Tools для тестирования или на старых серверах (хотя все VMware Tools можно скопировать с ESX напрямую), вам может оказаться полезной вот эта ссылка - http://packages.vmware.com/tools/esx/index.html.

Там все упорядочено по версиям VMware vSphere / ESX / ESXi:

Последняя версия VMware Tools находится в папке "latest". По свойствам папки легко обнаружить дату обновления.

Ну а на сервере VMware ESXi пакеты VMware Tools находятся тут - /vmimages/tools-isoimages/. Скопировать вы их можете с помощью Veeam FastSCP.

Ну и видео обновления VMware Tools - мало ли кому-то пригодится:

Интересное (но неофициальное) исследование на тему миграции на новую версию платформы VMware vSphere 5 опубликовано на блоге virtualgeek. Было опрошено 1935 респондентов. Напомним, что VMware vSphere 5 вышла в августе этого года.

Самый занимательный график - это ответы на вопрос "Какую версию VMware vSphere вы сейчас используете?" (допускалось более одного варианта ответа):

59,2% для vSphere 5 - это очень и очень большой показатель, учитывая выход продукта 4 месяца назад.

Полезен также график ответов на вопрос "Используете ли вы другие технологии виртуализации":

Ну Hyper-V понятно, но, фигасе, XenServer жжет. Неожиданно.

Далее вопрос о проценте виртуализованных серверов (но надо учитывать специфику исследования - отвечали люди, которые крутятся в сфере виртуализации). График в лучших традициях Чурова, но автор говорит, что результат где-то 86%.

Далее - тоже интереснейшая тема. Системы хранения каких вендоров используют под виртуализацию:

EMC на высоте - молодцы. Но, по-моему, автор из EMC, поэтому тоже надо на это делать скидку.

Ну и теперь - ответьте на вопросы для нашего небольшого исследования:

Опрос VM Guru - 4 вопроса!

Результаты будут вывешены как только наберется репрезентативная выборка. Спасибо!

Наконец-то хоть кто-то сделал (или я только узнал) человеческую утилиту для добавления custom-драйверов в дистрибутив (ISO) сервера VMware ESXi 5. На сайте v-front обнаружилось средство ESXi-Customizer:

Утилита ESXi Customizer полностью бесплатна и имеет GUI под Windows, однако, отметим, что такой способ вставки драйверов в дистрибутив ESXi не поддерживается со стороны VMware. Во время получения финального ISO-образа ESXi вы можете прервать процесс и поменять различные параметры целевого образа (в текстовом фале):

Скачать утилиту ESXi-Customizer можно по этой ссылке. Также по теме будет интересна вот эта статья.

Обновилась знаменитая шпаргалка по VMware vSphere от Forbes Guthrie - vSphere 5 vReference card (см тут). Теперь в нее добавлен раздел по установке серверов VMware ESXi 5:

Мы уже много писали о продукте №1 - vGate R2 от компании Код Безопасности, обеспечивающем сертифицированную защиту виртуальных сред VMware vSphere, а также автоматическую настройку инфраструктуры виртуализации в соответствии с политиками, отражающими стандарты и руководящие документы в сфере ИБ. Долгое время существенной проблемой являлось то, что продукт не поддерживал новую версию платформы VMware vSphere 5, на которую постепенно переходят предприятия. Но проблемы больше нет - вышел vGate R2 с поддержкой vSphere 5.

Хорошая новость от Veeam - теперь любой VCP, MVP, VCI, vExpert и просто участник какого-нибудь захолустного VMware User Group может получить бесплатную лицензию на Veeam Backup and Replication 6 на 2 процессора для тестирования дома и на работе. Однако помните, что выданные NFR-лицензии нельзя использовать в производственной среде (а можно только для тестирования и обучения).

Забрать свою лицензию можно по этим ссылкам:

• Для vSphere: http://www.veeam.com/nfr/free-nfr-license
• Для Hyper-V: http://www.veeam.com/nfr/free-nfr-license-hyper-v

Но 2 сокета - это как-то мало. Поставьте к этой статье NN лайков, и, возможно, Veeam увеличит количество выдаваемых сокетов (мы пообщаемся на эту тему, если вас будет много).

Вторая интересная новость: вышел отчет "Virtualization Data Protection 2011" от Veeam. Отчет представляет собой исследование 500 крупных компаний на предмет того, как они защищают данные в виртуальных средах.

Там есть интересная инфографика, как, например, стоимость часа простоя критической системы в разных странах (че-то вообще дофига):

В-общем, почитайте.

Интересная штука обнаружилась в настройках мониторинга VMware vSphere. Оказывается в vSphere Client можно вывести информацию о том, сколько электроэнергии потребляет отдельно взятая виртуальная машина на хост-сервере ESXi.

Для этого необходимо выставить экспериментальную настройку Power.ChargeVMs в Advanced Options (которая по-умолчанию установлена в 0) в значение 1 на каждом из хостов ESXi:

После этого мы получим вот такой график в vSphere Client, отражающий потребление виртуальной машиной электричества (видимо, высчитывается из актуальных значений загрузки хоста по памяти и процессору). Кликабельно:

Для чего это нужно? Очевидно, что для таких продуктов, как VMware vCenter Chargeback, который высчитывает, во сколько обходится содержание различных объектов виртуальной инфраструктуры VMware vSphere. Кстати, недавно вышло обновление - VMware vCenter Chargeback 2.0.

Еще очень давно компания VMware выпустила продукт VMware vCenter Orchestrator, который является платформой для автоматизации задач администраторов VMware vSphere. Этот продукт позволяет создать определенный рабочий процесс (Workflow), который представляет собой совокупность взаимосвязанных действий, которые, составив однажды, можно исполнять впоследствии, что очень помогает при типовых операцях в виртуальной инфраструктуре (например, миграция большого количества систем, создание пула ресурсов с тестовыми виртуальными машинами и т.п.). Эти рабочие процессы может выполнять уже не администратор, а, например, оператор, наделенный соответствующими полномочиями.

По-сути VMware vCenter Orchestrator - это фреймворк со своим GUI, который, кстати говоря, раньше использовался различными продуктами компании VMware (например, VMware Lifecycle Manager, на смену которому пришел VMware vCloud Director в части Request Manager). При этом функциональность Orachestrator может быть расширена за счет различных плагинов, которые предоставляют возможности интеграции как с объектами виртуальной инфраструктуры (например, развернуть новый хост ESXi за счет AutoDeploy), так и со сторонними приложениями (например, внести изменения в Active Directory). Вообще говоря, VMware vCenter Orchestrator - очень классная и мощная вещь, которая, зачастую, игнорируется администраторами vSphere (особенно продукт актуален для крупных развертываний).

На днях VMware объявила о выпуске сразу 4-х новых плагинов к VMware vCenter Orchestrator:

1. VMware vCenter Orchestrator SQL Plug-In. Этот плагин позволяет автоматизировать операции с базой данных (например, перевод ее в соответствующий режим или вставка записей). Теперь это может пригодиться при миграции баз данных или других операциях, требующих выполнения SQL-запросов перед операциями в виртуальной среде.

2. VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy.  Плагин позволяет ввести в строй новый сервер ESXi и выполнить далее, например, операции по развертыванию на нем парка ВМ. 

3. vCenter Orchestrator Multi-Node Plug-In.  Плагин для управления несколькими экземплярами VMware vCenter Orchestrator.

4. vCenter Orchestrator Plug-In for Microsoft Windows PowerShell.  Самый долгожданный плагин, позволяющий добавить в рабочий процесс сценарии PowerCLI, которых на сегодняшний день написано огромное множество.

Выглядят плагины так (смотрите, сколько там еще всего интересного):

Скачать все эти плагины можно по этим ссылкам:

• VMware vCenter Orchestrator SQL Plug-In: release notes, documentation and download
• VMware vCenter Orchestrator Plug-In for vSphere Auto Deploy: release notes, documentation and download
• VMware vCenter Orchestrator Multi-Node Plug-In: release notes, documentation and download
• VMware vCenter Orchestrator Plug-In for Microsoft Windows PowerShell: release notes, documentation anddownload

Мы уже писали о том, что недавно вышла бета-версия StarWind 5.8 - продукта номер 1 для создания отказоустойчивых хранилищ iSCSI под виртуальные машины Hyper-V и VMware vSphere (загрузить бету можно по этой ссылке).

Как многие знают, продукт поставляется в двух версиях: собственно StarWind Enterprise HA 5.8 для виртуальных машин на серверах ESX / ESXi, а также решение StarWind Native SAN for Hyper-V, которое является уникальным в своем роде: с помощью него мождо сделать кластер отказоустойчивости как для серверов, так и для хранилищ (см. тут).

Для версии продукта под Hyper-V появилось интересное нововведение - возможность резервного копирования виртуальных машин Hyper-V:

ArCycle Backup for Hyper-V - это плагин к StarWind Native SAN 5.8, который позволяет копировать виртуальные машины с нескольких серверов Hyper-V и сохранять резервные копии на пуле серверов хранилищ. Его основные возможности:

• Простая установка
• Высокая скорость резервного копирования и восстановления
• Единая центральная консоль как для организаци хранилищ, так и управления резервным копированием
• Работает без агентов в виртуальных машинах
• Без простоя виртуальных машин
• Поддержка дедуплкации целевых хранилищ резервных копий
• Реализовано в виде сервиса VSS
• Режим "sandbox"

Попробуйте - особенно для виртуальных машин Hyper-V должно работать хорошо. Пробную версию продукта StarWind Enterprise 5.8 Beta можно скачать по этой ссылке. Бесплатная версия продукта доступна тут.

Помните, мы писали, что снапшоты виртуальных машин в VMware vSphere - это плохо? Но иногда без них не обойтись - например, системы резервного копирования (например, Veeam Backup and Replication) вынуждены делать снапшоты, чтобы не прерывать работу виртуальной машины во время бэкапа.

Цель этой заметки - показать, что в VMware vSphere при работе со снапшотами все сделали несколько лучше, чем в предыдущей версии. Во-первых, смотрим это видео:

Мысль видео такова: если у вас некорректно завершилась операция по консолидации снапшотов, то в VMware vSphere 5 вам предлагается опция по консолидации, доступная из контекстного меню виртуальной машины:

То есть, теперь не надо терзать командную строку в случае появления проблем со снапшотами виртуальных машин.

Во-вторых, появилась опция по поиску виртуальных машин, нуждающихся в консолидации снапшотов, доступная из vSphere Client. Чтобы найти такие машины, нужно выбрать хост или кластер, перейти на вкладку "Virtual Machines" и по правой кнопке выбрать пункт "Needs Consolidation":

Ну и, в-третьих, в vSphere 5 полностью поддерживается "горячее" перемещение виртуальных машин между хранилищами средствами Storage vMotion, а также, само собой, между хостами средствами обычного vMotion.

Картинки честно украдены у Vladan'а Seget'а.

На сайте проекта VMware Labs, где в последнее время часто появляются полезные утилиты от сотрудников VMware, опубликована новая штучка - VMware I/O Analyzer, виртуальный модуль (Virtual Appliance) для анализа статистики по вводу-выводу.

Данное ПО включает в себя стандартные средства для измерения производительности систем хранения VMware vSphere, которые позволят выявить проблемы и узкие места в инфраструктуре хранилищ.

Ключевые возможности VMware I/O Analyzer:

• Интегрированный фрейворк для тестирования хранилищ
• Готовый к развертыванию виртуальный модуль
• Прост в настройке и возможность исполнения тестов на нескольких хостах ESX/ESXi
• Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС
• Возможность экспорта данных для последующего анализа

Скачать VMware I/O Analyzer можно по этой ссылке. Инструкция по развертыванию доступна тут.

Многие пользователи VMware vSphere не пользуются средством автоматизированного обновления хост-серверов VMware Update Manager по тем или иным причинам. Кроме того, пользователи бесплатного VMware ESXi 5 хотели бы обновлять свои хост-серверы, потому как даже эта бесплатная платформа используется в компаниях в производственной среде. Если раньше можно было обновлять хосты ESX/ESXi 4 прямо из vCLI (vihostupdate), то теперь патч нужно загрузить на хранилище (Datastore).

Ниже представлен способ обновления VMware ESXi 5 без VMware Update Manager:

1. Загрузите нужный патч для VMware ESXi 5 с VMware Patch Portal в формате zip-файла.

2. Убедитесь, что на хосте включен доступ по SSH, а также на нем нет запущенных виртуальных машин (или переведите его в Maintenance Mode).

3. Скопируйте патч ESXi 5 в один из Datastore'ов (общий или локальный) с помощью бесплатной утилиты FastSCP. Лучше использовать общее хранилище, чтобы с одного файла патча обновлять несколько хостов.

4. Выполните команду консоли:

esxcli software vib install -d /vmfs/volumes/[DATASTORE]/[PATCH_FILE].zip

5. После этого начнется обновления хост-сервера VMware ESXi 5, по окончании которого его нужно будет перезагрузить.

Патч для ESXi можно накатить и через PowerCLI (но загрузить патч на Datastore все равно придется). Для этого можно использовать скрипт от Justin Guidroz.

Возвращаемся к проблеме тонких (thin) дисков VMware ESXi и уменьшения их размера после того, как они разрослись. Суть проблемы: когда вы используете тонкие диски для виртуальных машин - они постоянно растут, даже если вы удаляете в гостевой ОС. Это происходит потому, что ОС Windows (да и Linux) при удалении файлов не заполняет их блоки нулями, а просто помечает их удаленными в метаданных тома.

Как вы знаете, с появлением VMware vSphere 5 появилось несколько новых возможностей платформы виртуализации и новых компонентов решения. Однако мы хотим сосредоточиться на том, какие компоненты больше не являются частью VMware vSphere 5.

Итак чего больше нет в vSphere 5:

• Гипервизора ESX. Остался только ESXi. Все дальнейшие версии vSphere будут только на платформе ESXi.
  
  
• Продукта VMware Converter Enterprise, поставлявшегося в виде плагина к vCenter. Читаем в Release Notes:
  
  "VMware vSphere 4.1 and its  subsequent update and patch releases are the last releases for the  VMware vCenter Converter plug-in for vSphere Client. VMware will  continue to update and support the free Converter Standalone product,  which enables conversions from sources such as physical machines, VMware  and Microsoft virtual machine formats, and certain third-party disk  image formats."
  
  То есть больше нет вот этого пункта меню в vSphere Client:
  
  
  
  Теперь вы можете использовать только VMware vCenter Converter Standalone (он бесплатен).
  
  
• Обновления гостевых ОС через VMware Update Manager. Ранее гостевые ОС можно было обновлять средствами VUM через репозитории Shavlik, компании, которая не так давно была куплена компанией VMware. Теперь возможность обновления гостевых ОС есть в двух продуктах: VMware vCenter Protect Essentials и VMware vCenter Configuration Manager, приобретаемых отдельно от vSphere 5.
  
  
• Компонента Guided Consolidation, позволявшего провести базовое исследование по миграции физических серверов в виртуальную среду VMware vSphere. Теперь вы можете использовать только VMware Capacity Planner, доступный со стороны партнеров VMware.
  
  
  
  
• VMware Consolidated Backup теперь полностью исключен из списка поддерживаемых продуктов (для четвертой версии vSphere поддержка еще существовала). Вместо него используется vStorage API for Data Protection, используемый, например, в Veeam Backup and Replication 6.
  
  
• Также нужно отметить, что несмотря на то, что VMware ESXi и VMware vCenter - полностью 64-битные продукты, некоторые компоненты, а именно: VMware Update Manager 5.0, View Composer (из поставки VIew), vSphere Client - по-прежнему 32-битные приложения.

На сайте проекта VMware Labs, где публикуются результаты внутренних разработок VMware (т.е. утилиты, которые факультативно разрабатываются сотрудниками компании) появилась новая утилита ESX System Analyzer.

ESX System Analyzer - это утилита, поставляемая в виде готового виртуального модуля (Virtual Appliance), которая позволяет пользователям спланировать миграцию хост-серверов ESX на платформу ESXi. Она анализирует серверы ESX в виртуальной инфраструктуре и собирает для каждого хоста информацию, которую необходимо учитывать в процессе миграции:

• Аппаратную совместимость серверов с ESXi
• Виртуальные машины, зарегистрированные на хосте ESX, а также ВМ, которые находятся на локальных дисках
• Отличия настроек компонента Service Console от стандартных:
  • RPM-пакеты, которые были добавлены или удалены
  • Файлы в сервисной консоли, которые добавляли пользователи
  • Добавленные пользователи и задачи cron

• Версии VMware Tools и Virtual Hardware для всех виртуальных машин
• Версии файловых систем для томов VMFS

• Переместить ВМ с локальных дисков на общие хранилища
• Понять, как можно заменить агентов в сервисной консоли на их безагентные альтернативы или CIM-агенты
• Заменить задачи cron удаленными скриптами PowerCLI или vCLI

Системные требования к ВМ, содержащей ESX System Analyzer (работа с утилитой производится через веб-интерфейс):

• 20GB virtual disk
• 512MB virtual memory
• 1 vCPU
• vCenter Server 2.5, 4.0, 4.1, 5.0
• ESX Hosts 3.5, 4.0, 4.1
• Административный доступ к vCenter Server
• Root password для анализируемых ESX
• Включенный доступ Root по SSH на всех хостах

Скачать ESX System Analyzer можно по этой ссылке. Инструкция по работе с продуктом - тут.

Многие из вас знают продукт номер 1 для резервного копирования виртуальных машин VMware vSphere - Veeam Backup and Replication. Мы уже много писали как о функциональности Veeam Backup and Replication 5, так и о новых возможностях, которые появляются в Veeam Backup and Replication 6. В среду, 30 ноября, должен состояться релиз новой версии продукта, поэтому постараемся в этой статье собрать все новые функции, улучшения и нововведения Veeam Backup and Replication 6 (обратите также внимание на повышение цен на продукт с 1 декабря).

Приведенная ниже информация основана на документе "Veeam Backup & Replication. What's new in v6", который вы можете почитать в оригинале для понимания всех аспектов новых возможностей этого средства для резервного копирования виртуальных машин.

Новые ключевые возможности и улучшения Veeam Backup and Replication 6:

• Enterprise scalability: улучшенная архитектура продукта позволяет производить развертывание в удаленных офисах и филиалах, а также для больших инсталляций. Теперь появилось несколько backup proxy серверов для крупных окружений (data movers), которые могут распределять между собой нагрузку в процессе резервного копирования, а управляет процессом сервер Veeam Enterprise Manager. Виртуальные машины динамически назначаются proxy-серверам с учетом алгоритма балансировки нагрузки, что снижает затраты на администрирование инфраструктуры РК. Также увеличена производительность для резервного копирования, репликации и восстановления по WAN-каналам.
• Advanced replication: в некоторых случаях скорость репликации выросла до 10 раз, а также появится Failback (обратное восстановление виртуальной машины после возобновления работы отказавшего хоста с ВМ) с возможностью синхронизации дельты (различия данных с момента отказа основной машины на основном сервере и хранилище - Failover). Кроме того, поддерживается репликация в thin provisined-диски на целевой сервер. Это сильная заявка на победу над VMware SRM 5 (в издании Standard) для небольших компаний, где серверов не много и нужно укладываться в небольшие бюджеты. Появилась также возможность создания реплик базового образа для окружений VMware View.
• Multi-hypervisor support: полная поддержка Windows Server с ролью Hyper-V и Microsoft Hyper-V Server, а также возможность управления резервным копированием для гипервизоров разных производителей из одной консоли. Одна и та же инсталляция Veeam Backup позволит делать резервные копии и с VMware vSphere, и с Microsoft Hyper-V. При этом лицензирование также единое - один пул лицензий Veeam вы можете распределить между лицензиями на процессоры для хостов ESXi и Hyper-V. Кроме того, появилась поддержка методики Changed Block Tracking для Hyper-V для ускорения процесса инкрементального резервного копирования (отслеживание изменившихся блоков с момента последнего бэкапа).
• 1-Click File Restore - с помощью 1-Click File Restore можно зайти в Enterprise Manager, выбрать нужный файл и восстановить туда, откуда он был удален (это можно сделать также из результатов поиска файла по резервным копиям). При этом есть разделение ролей - есть тот, кто может файл восстановить (helpdesk), а есть тот, кто открыть. Данная возможность доступна только в Enterprise Edition.

Полный список новых возможностей:

Архитектура Veeam Backup and Replication 6

• ESXi-centric processing engine - теперь архитектура продукта полностью опирается на архитектуру ESXi, но в поддержка гипервизора ESX остается в полной мере.
• Backup proxy servers - один сервер Veeam Backup может контролировать несколько прокси-серверов, обеспечивающих передачу данных на целевые хранилища. Прокси-серверы не нуждаются в Microsoft SQL
  Server и содержат минимальный набор компонентов.
• Backup repositories - новая концепция репозиториев резервного копирования (в традиционном РК известная как медиа-серверы), которые хранят настройки задач резервного копирования и параметры целевых хранилищ. Задачи по РК виртуальных машин с помощью медиа-серверов динамически назначаются proxy-серверам с учетом алогоритма балансировки нагрузки.
• Windows smart target - в дополнение к Linux target agent, который помогает при резервном копировании в удаленные хранилища, появился также агент для Windows. Этот агент на целевой машине позволяет производить эффективную компрессию и обновлять синтетические резервные копии.
• Enhanced vPower scalability - теперь можно использовать несколько серверов vPower NFS. Теперь можно запускать еще больше ВМ напрямую из резервных копий (например, если у вас много ВМ с большими дисками это очень может помочь). Любой сервер РК Veeam или Windows backup repository может быть таким сервером.

Ядро продукта Veeam Backup and Replication 6

• Optimization of source data retrieval - теперь учитываются параметры дисковых хранилищ при обращении к виртуальным машинам. Это позволяет до 4-х раз увеличить производительность для одной операции, в зависимости от настроек дискового массива.
• Reduced CPU usage - теперь в два раза меньше нагрузка задач на процессор, что позволяет запустить больше задач РК или репликации на одном сервере Veeam Backup или прокси-сервере.
• Traffic throttling - теперь доступны опции по регулированию полосы пропускания, которые производятся на базе пары source/target IP. Эти правила могут быть основаны на времени операций - время дня или день недели.
• Multiple TCP/IP connections per job - теперь агенты Data Movers могут инициировать соединение по нескольким IP-адресам, что существенно увеличивает скорость резервного копирования. Особенно это эффективно для репликации по WAN-каналам.
• WAN optimizations - протокол передачи данных Veeam Backup был существенно доработан в плане производительности для передачи данных по соединениям с большими задержками в канале.
• Exclusion of swap files - блоки, относящиеся к файлам подкачки, теперь исключаются из передачи в резервную копию, что существенно увеличивает производительность.
• Enforceable processing window - теперь для каждой задачи можно задавать окно РК или репликации (все задачи, не попадающие в это окно завершаются). Также вне рамок окна не разрешается применение снэпшотов, что не позволяет оказывать влияние на производительность ВМ в рабочие часы.
• Parallel backup and replication - теперь задачи, относящиеся к одной и той же ВМ, могут быть выполнены параллельно. Например, вы можете запускать ежедневную задачу Full Backup параллельно с работающей задачей репликации.

Улучшения резервного копирования в Veeam Backup and Replication 6

• Backup mapping - при создании новой задачи резервного копирования ВМ, ее можно присоединить к уже имеющейся задаче (например, в ней есть уже файлы этой ВМ). В этом случае Full Backup этой ВМ может не потребоваться.
• Enhanced backup file format - новый формат метаданных позволяет осуществлять быстрый импорт резервных копий, а также закладывает основу для поддержки новой функциональности в следующих релизах продукта.
• Backup file data alignment - данные ВМ, сохраненные в бэкап-файле, могут быть размещены в пределах блоков по 4 КБ. Это увеличивает производительность дедупликации как самого Veeam Backup, так и сторонних технологий дедупликации (например, средствами дискового массива).
• Improved compatibility with deduplicating storage - теперь механизм РК оказывает меньшее влияние на предыдущие файлы резервной копии, что улучшает производительность массивов, которые осуществляют пост-процессинг хранимых данных.

Репликация Veeam Backup and Replication 6

• New replication architecture - теперь репликация использует двухагентную архитектуру, которая позволяет собирать данные хранилищ ВМ на исходном DR-сайте одним прокси-сервером РК и посылать их напрямую к прокси-серверу резервной площадки (и наоборот), минуя главный сервер Veeam Backup. Поэтому теперь не разницы, где размещать последний.
• Replica state protection - теперь инкрементальные задачи репликации больше не обновляют последнюю точку восстановления ВМ. Это позволяет при прерывании задачи не перестраивать последнюю точку восстановления до того, как следующая задача откатит ее к последнему согласованному состоянию, как в прошлых версиях. В версии 6 последняя точка восстановления всегда согласована и ВМ может быть запущена в любой момент.
• Traffic compression - за счет новой архитектуры репликации теперь не важно где находится основной сервер РК Veeam, а трафик сжимается намного более эффективно. Кроме того, появились настройки уровня компрессии для передаваемого трафика, что позволяет уменьшить требования к полосе пропускания до 5 раз.
• Hot Add replication - теперь прокси-сервер на целевой площадке представляет диски реплики, используя технологию Hot Add. Это уменьшает поток трафика до 4 раз.
• 1-click automated failback - позволяет произвести обратное восстановление (Failback) виртуальной машины после возобновления работы отказавшего хоста с ВМ с возможностью синхронизации только дельты с момента последнего отказа (Failover), т.е. различия данных с момента отказа основной машины на основном сервере и хранилище) . Перед завершением этого процесса можно проверить ВМ на работоспособность на основной площадке.
• 1-click permanent failover - возможность в один клик провести все необходимые процедуры по завершению процесса превращения резервной машины в основную, когда в случае отказа основной ВМ она переместилась на резервный сайт.
• Active rollbacks - репликация теперь хранит точки восстановления как обычные снапшоты ВМ. Это позволяет откатиться в любую точку на резервной площадке, даже без участия Veeam Backup.
• Improved replica seeding - улучшения механизма организации репликации. Теперь репликация использует обычные бэкап-файлы, это позволяет уменьшить размер передаваемых данных, поддерживаются ВМ с тонкими (thin) дисками и многое другое.
• Replica mapping - теперь реплицируемую виртуальную машину можно привязать к уже существующей ВМ на резервной площадке (например, ранее для нее использовалась репликация или на резервную площадку ее восстановили из резервной копии). Это позволяет не передавать весь объем данных для создания реплицируемой пары.
• Re-IP - теперь можно задать правила автоматического назначения IP-адреса для восстанавливаемой ВМ. Это очень полезно, когда требуется восстановить ВМ на резервную площадку, где действует другая схема IP-адресации, в случае сбоя основной.
• Cluster target - задачи репликации теперь поддерживают указание определенного хоста или кластера как целевого для репликации. Это позволяет убедиться в том, что при восстановлении ВМ она окажется доступной (например, на резервной площадке).
• Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches технологией репликации, что позволяет передавать состояние реплики без дополнительных ручных операций (например, в окружениях с VMware vCloud Director).
• Automatic job update - операции failover и failback автоматически обновляют задачу репликации путем исключения из нее ВМ и повторного добавления.
• Multi-select operations - в консоли теперь можно выбрать несколько ВМ для операций с репликацией. Например, при массовом выходе из строя хостов можно провести операции failover сразу с несколькими ВМ (аналогично и для failback).
• Enhanced job configuration - теперь мастер создания реплицируемой пары поддерживает возможность настройки репликации на уровне vmdk-дисков, а также предоставляет возможность настроить целевые объекты: resource pool, VM folder и virtual network, где будет размещаться реплика и восстанавливаться ВМ.

Миграция виртуальных машин в Veeam Backup and Replication 6

• Quick Migration - эта технология позволяет организовать миграцию виртуальной машины между хостами и/или хранилищами путем передачи данных ВМ в фоновом режиме (пока она запущена) и потом на время простоя (переключения) передается только дельта файлов vmdk. Переключение осуществляется с помощью технологии SmartSwitch или просто повторной загрузкой ВМ. По сути, эта функция - аналог vMotion и Storage vMotion, но с небольшим простоем ВМ.
• SmartSwitch - эта технология позволяет передать текущее состояние ВМ от исходного хоста и хранилища к источнику на время переключения виртуальной машины между ними (с простоем). При этом процессоры исходного и целевого хостов должны быть совместимы по инструкциями.
• Migration jobs - новый тип задач "миграция ВМ". С учетом имеющейся у вас лицензии на VMware vSphere, мастер миграции выполняет одну из следующих задач: VMware vMotion, VMware Storage vMotion, Veeam Quick Migration
  with SmartSwitch или Veeam Quick Migration with cold switch. Это позволяет быстро перевести ВМ с хостов, для которых требуется срочное обслуживание или останов (например, электричество выключили, а они на UPS'ах) или перенести ВМ в другой датацентр с минимальным влиянием на доступность сервисов в ВМ.
• Instant VM Recovery integration - задачи миграции ВМ теперь оптимизированы для работы с функцией Instant VM Recovery. Если задача миграции обнаруживает, что ВМ переносится из состояния, когда она была мгновенно восстановлена (т.е. дельта размещается на vPower NFS datastore), то постоянная составляющая этой ВМ берется из бэкап-файла, а различия уже с NFS-хранилища для ускорения процесса миграции и оптимизации производительности.
  

Копирование файлов в Veeam Backup and Replication 6

• Support for copying individual file - поддержка копирования отдельных файлов. Задача по копированию файлов теперь поддерживается так же, как и для каталогов.

Восстановление виртуальных машин в Veeam Backup and Replication 6

• 1-click VM restore - при восстановлении ВМ в исходное размещение (самый частый случай), это может быть сделано в один клик.
• Virtual Disk Restore wizard - новый режим восстановления позволяет восстановить отдельные vmdk-диски в их исходное размещение или присоединить к другой или новой ВМ. При этом мастер Virtual Disk Restore может восстанавливать диски как "thin" (т.е. растущими по мере наполнения данными), а также делает все необходимые настройки в заголовочном vmdk-файле.
• Hot Add restores - Veeam Backup первым стал поддерживать технологию Hot Add не только для РК, но и для восстановления vmdk-дисков, что позволяет избежать проблем производительности.
• Multi-VM restore - возможность восстановления сразу многих ВМ из графического интерфейса, что очень удобно для случаев массовых отказов хранилищ или хост-серверов.
• Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches и улучшения в интерфейсе по интеграции с ним (что удобно, например, при использовании совместно с vCloud Director).
• Network mapping - при восстановлении виртуальных машин на сервер или площадку с другой конфигурацией виртуальных сетей, можно указать новые параметры сетевого взаимодействия.
• moRef preservation - при восстановлении ВМ с заменой существующей копии, ее идентификатор сохраняется, что позволяет не перенастраивать задачи Veeam, а также стороннее ПО, работающее с виртуальными машинами по их идентификатору (почти все так и работают).
  

Восстановление на уровне файлов в Veeam Backup and Replication 6

• Support for GPT and simple dynamic disks - теперь восстановление на уровне файлов поддерживает тома GPT и simple dynamic disks.
• Preservation of NTFS permissions - опционально при восстановлении файлов Windows можно сохранить владельца и права на них в NTFS.

Индексирование и поиск файлов в резервных копиях Veeam Backup and Replication 6

• Optional Search Server - теперь поиск по файлам гостевой ОС работает без Microsoft Search Server. Однако он рекомендуется для больших окружений с сотнями ВМ для лучшей производительности.
• Reduced catalog size - размер каталога файловой системы гостевых ОС существенно уменьшился, что позволяет экономить место на сервере Veeam Backup.
• User profile indexing - появилась поддержка индексации профиля пользователя в гостевой ОС.
  

Статистика и отчетность в Veeam Backup and Replication 6

• Enhanced real-time statistics - теперь статистика в реальном времени по задачам РК улучшена в плане дизайна, чаще обновляется и более информативна для пользователя.
• Improved job reports - отчеты о задачах РК лучше выглядят, имеют дополнительную информацию, включая количество изменившихся данных, уровень компрессии и коэффициент дедупликации.
• Bottleneck monitor - в ответ на наиболее частые вопросы о низкой производительности в различных окружениях, Veeam сделала новый компонент, который позволяет выявить узкие места на различных стадиях РК и репликации. Все это отображается в статистике реального времени.
• VM loss warning - история задач РК теперь оповещает пользователя о виртуальных машинах, которые раньше бэкапились, а потом задачи РК перестали существовать (например, случайно или намеренно удалили).
  

Интерфейс пользователя консоли Veeam Backup and Replication 6

• Wizard improvements - все мастера были обновлены для возможности быстрой навигации при создании задач РК. Некоторые мастера стали динамическими - т.е. сфокусированными только на той задаче, которую вы хотите выполнить.
• VM ordering - мастера резервного копирования и репликации теперь позволяют задать порядок, в котором ВМ должны обрабатываться.
• Multi-user access - доступ нескольких пользователей к консоли теперь включен по умолчанию, позволяя нескольким пользователям получить доступ к консоли по RDP на одном сервере.
  

Веб-интерфейс Enterprise Manager в Veeam Backup and Replication 6

• Job editing - в дополнение к управлению задачами, Enterprise Manager позволяет теперь менять их настройки для защищаемых ВМ, бэкап-репозитории, учетную запись гостевой ОС - все прямо из веб-интерфейса.
• Job cloning - существующие задачи теперь могут быть клонированы прямо из веб-интерфейса с сохранением всех настроек.
• Helpdesk FLR - появилась новая роль "File Restore Operator" в Enterprise Manager, которой делегированы полномочия по восстановлению отдельных файлов. Ее можно назначить персоналу службы help desk. При этом файлы восстанавливаются в их исходное размещение, а персоналу hepl desk можно ограничить возможности их скачивания, и, соответственно, доступа к ним (есть настройки касательно типов файлов и прочее).
• FIPS compliance - веб-интерфейс теперь полностью совмести с стандартом FISP.
• Design improvements - веб-интерфейс имеет множество улучшений в плане юзабилити и дизайна.

Улучшения технологии SureBackup в Veeam Backup and Replication 6

• Improved DC handling - теперь улучшена работа с контроллерами домена в ситуациях, когда он оказывается изолированным в окружениях с несколькими DC.
• Support for unmanaged VMware Tools - задачи SureBackup теперь поддерживают виртуальные машины с пакетами VMware Tools, которые установлены вручную.
  

Остальные улучшения Veeam Backup and Replication 6

• Enhanced PowerShell support - расширены возможности PowerShell API, что позволяет управлять всеми настройками Veeam Backup. Все командлеты PowerShell были упрощены в плане синтаксиса (старый синтаксис также поддерживается). Появились маски в именах объектов, поиск объектов - все аналогично возможностям в консоли.
• Log collection wizard - новый мастер, который собирает лог-файлы с защищенных хостов и подготавливает пакет, необходимый при обращении в техподдержку Veeam.
• 1-click automated upgrade - все компоненты продукта, включая те, что установлены на удаленной площадке (backup
  proxy servers и backup repositories), могут быть просто обновлены с использованием мастера Upgrade wizard. При открытии консоли, Veeam Backup & Replication автоматически определяет компоненты решения, которые следует обновить.

Продукт Veeam Backup and Replication 6 должен быть доступен для скачивания с сайта Veeam ориентировочно в среду на странице загрузки продукта.

Несколько скриншотов. Восстановление файла резервной копии из результатов поиска в Enterprise Manager:

Настройки Traffic Throttling:

Мастер восстановления виртуальной машины Microsoftc Hyper-V:

Настройка бэкап-репозиториев:

Настройки Re-IP при восстановлении на резервной площадке:

Часто бывает, что от хоста ESX/ESXi нужно отвязать Datastore и LUN, на котором это виртуальное хранилище находится. При этом важно избежать ситуации All Paths Down (APD) - когда на хосте все еще остались пути к устройству, а самого устройства ему больше не презентовано. В этом случае хост ESX/ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути.

В этом случае из-за APD хоста начнут возникать задержки других задач (поскольку таймауты большие), что может привести к различным негативным эффектам вплоть до отключения хоста от vCenter.

ESX/ESXi 4.1

В версии ESX/ESXi 4.1 демон hostd проверяет том VMFS на доступность прежде чем слать туда команды ввода-вывода (I/Os) Но это не помогает для тех I/O, которые находятся в процессе в то время, когда случилась ситуация APD.

Как описано в KB 1015084, правильно отвязывать LUN с хоста ESX/ESXi 4.1 так (все делается на каждом из хостов):

1. Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
2. Убедиться, что этот datastore не используют сторонние программы.
3. Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control) больше не используются для этого устройства.
4. Замаскировать LUN на хосте ESX/ESXi, следуя инструкциям KB 1009449 через модуль PSA (Pluggable Storage Architecture).
5. Со стороны дискового массива распрезентовать LUN от хоста.
6. Сделать "Rescan for Datastores" на хосте ESX/ESXi.
7. Удалить правила маскирования LUN, которые вы сделали на шаге 4 по инструкции в KB1015084.
8. Убедиться, что не осталось путей к устройству, после того, как вы проделали все эти операции.

Для ESX/ESXi 4.1 процесс достаточно сложный, теперь давайте посмотрим, как это выглядит в ESXi 5.

ESXi 5.0

В ESXi 5.0 появился новый статус  Permanent Device Loss (PDL), то есть когда хост считает, что дисковое устройство уже никогда не будет снова подключено, а ситуация APD рассматривается как временный сбой, после которого хост снова увидит пути и устройство.

Чтобы избавиться от сложной процедуры отключения LUN от хостов ESXi, VMware сделала операции detach и unmount в интерфейсе vSphere Client и в командном интерфейсе CLI.

Вот тут можно найти unmount Datastore (но устройство продолжит быть доступным):

А вот тут находится detach для самого устройства:

Как описано в KB 2004605, чтобы у вас не возникло ситуации APD, нужно всего-лишь сделать detach устройства от хоста. Это размонтирует VMFS-том (если там есть какие-нибудь объекты - vSphere Client вам сообщит об этом).

Таким образом правильная последовательность отключения LUN в ESXi 5.0 теперь такова:

1. Разрегистрировать все объекты с этого Datastore (если они там есть), включая шаблоны - правой кнопкой по объекту, Remove from Inventory.
2. Убедиться, что этот datastore не используют сторонние программы.
3. Убедиться, что никакие из фичей vSphere для хранилищ (например, Storage I/O Control или Storage DRS) больше не используются для этого устройства.
4. Сделать detach устройства на хосте ESXi, что также автоматически повлечет за собой операцию unmount.
5. Со стороны дискового массива распрезентовать LUN от хоста.
6. Сделать "Rescan for Datastores" на хосте ESXi.

Ну и в качестве дополнительного материала можно почитать вот эти статьи:

• vSphere 5.0 Storage Features Part 8 - Handling the All Paths Down (APD) condition
• Unpresenting a LUN in ESXi 5.x
• Unpresenting a LUN containing a datastore from ESX 4.x and ESXi 4.x
• Best Practice: How to correctly remove a LUN from an ESX host

Мы уже много рассказывали о продукте vGate R2, который позволяет защитить инфраструктуру от несанкционированного доступа и настроить ее в соответствии со стандартами и лучшими практиками на базе политик (в т.ч. ФЗ 152). Кроме того, у vGate R2 есть все необходимые сертификаты ФСТЭК, которые помогут вам пройти сертификацию в соответствующих органах. Мы много писали о работе с продуктом со стороны администратора (см. тут и тут), а сегодня опишем, как это выглядит со стороны пользователя.

Некоторые из вас, конечно же, как-то раз задумывались - а не открыть ли мне свой бизнес по сдаче в аренду виртуальных машин VMware vSphere? У каждого клиента будут свои виртуальные машины, я буду собирать с них помесячно плату, они уже никуда не соскочат, а мне останется лишь собирать деньги, да знай себе поддерживать инфраструктуру и наращивать мощности.

Я как человек в этом немного покрутившийся, могу вам сказать, что здесь не все так просто, и сам бы я такой бизнес профильным не сделал бы ни за что на свете. Но для тех, кого все-таки не оставляет эта идея, ниже приведены некоторые моменты об организации облака на основе решений VMware, виртуальные машины из которого вы можете предоставлять как услугу.

Начнем с того, что обычные лицензии VMware, которые вы покупаете у одного из партнеров или получаете как Internal Use Licenses, не позволяют вам сдавать виртуальные машины в аренду (внешним пользователям, не в своей организации) - это прямо запрещено пользовательским соглашением (EULA). Поэтому для таких дельцов придумана программа VSPP - VMware Service Provider Program (за само партнерство в программе платить не надо).

Программа VSPP направлена для сервис-провайдеров, телеком-операторов, интернет-провайдеров, поставщиков услуг, системных интеграторов и ИТ-подразделений корпораций, которые "продают" ИТ-ресурсы дочерним или аффилированным компаниям.

Эта программа позволяет вам получить некоторый пакет продуктов в рамках вашего партнерства с VMware по программе VSPP и начать предоставлять пользователям виртуальные машины (но не только!) в аренду, используя множество программных продуктов: vSphere, vCloud Director, vShield, View и многое другое. Всего есть несколько уровней партнерства по VSPP, у каждого из которых есть свои преимущества и требования.

Здесь нужно выделить 2 ключевых момента - это очки (points) и Aggregator (агрегатор) VSPP. Начнем с агрегатора. На самом деле вы не можете подписать контракт с VMware и начать сдавать в аренду ее машины и отчислять ей платежи. Это потому, что VMware ведет бизнес в каждой стране по своему и там ей нужны партнеры, которые посредством своих мутных схем и офшоров будут гонять бабло между, например, Россией, Кипром, ОАЭ и Америкой с одной стороны, а с другой - между юрлицом в России и российскими партнерами VMware.

Собственно, агрегатор - это тот же дистрибьютор, только касаемо облачных сервисов VMware. Но у него есть и некая техническая функция. Когда вы вписываетесь в VSPP, у вас в инфраструктуре vSphere развертывается специальное ПО на сервере vCenter, котороя смотрит сколько расходуется у вас ресурсов для виртуальных машин и посылает эти данные агрегатору. Делается это ежемесячно.

Далее агрегатор посылает эти данные в VMware на аудит, а сам выставляет вам счет, чтобы собрать бабло, которое дальше через офшоры и серые схемы потечет в VMware. В России таких агрегаторов несколько, и вы их найдете без труда.

Далее ключевой момент это очки (points), которые вы покупаете (а точнее, арендуете) ежемесячно, чтобы иметь право предоставлять некоторое количество услуг на базе продуктов VMware (чаще - виртуальных машин) в аренду. Самое важное тут то, что в большинстве случаев единицей тарификации является сконфигурированная оперативная память виртуальных машин (vRAM) - очки за 1 ГБ. Но есть и другие варианты тарификации для некоторых продуктов:

Но вас, скорее всего, интересует только Infrastructure as a Service (IaaS) - то есть, собственно, сдача виртуальных машин в аренду (то, что выделено красным). На сами цифры не смотрите - они американские и для нас неактуальные.

Для нас интересны вот эти 2 набора (эти цифры, вроде, актуальные):

VSPP Standard Bundle - это, по-сути, VMware vSphere 5 + Chargeback (для внутреннего биллинга) + vCloud Director (система управления датацентром с точки зрения облака - выделение ВМ и ресурсов, задание уровней сервиса, управление пользователями и т.п.). Для нас он стоит 5 очков в месяц за 1 ГБ памяти виртуальных машин (ниже я расскажу какой гигабайт). Второй VSPP Enterprise Bundle включает в себя еще и продукт vShield Edge для комплексной защиты периметра датацентра (см. подробнее тут и тут).

Теперь о тарификации этого самого гигабайта. Вы уже поняли, что единица стоимости - это 1 point, сколько он стоит в России я вам не скажу, но скажу, что в Америке 1 point = 1$. А суть лицензирования гигабайта такова:

• Вы создаете виртуальные машины для аренды и выставляете им vRAM Reservation, но не менее 50% (требование VMware) от сконфигурированной памяти.
• Максимально учитывается на одну ВМ - не более 24 ГБ.
• Умножаете ваш бандл (например, для Standard - это 5 очков) на число vRAM ваших ВМ и на долю зарезервированных ресурсов (например, для 50% это, понятное дело, 0,5). Получаете общее количество очков в месяц, за которые вам надо платить агрегатору.
• Выключенные ВМ не тарифицируются.

Как видно, у сервис-провайдера VSPP тоже есть некоторые права - вы можете гарантировать меньше ресурсов и меньше платить, либо обеспечить 100%-й SLA, но платить больше.

Смотрим на пример расчета:

Ну и каждый месяц агрегатор смотрит, сколько у вас набежало использованных очков, способствует продвижению уровня партнерства VSPP и выбиванию скидок за объем потребляемых поинтов. Вот тут есть хороший FAQ по программе VSPP, а тут - презентация.

Вкратце - это все. Тема у нас пока эта очень муторная. Если инетересно дальше - могу дать контакт с кем можно поговорить на эту тему. Ну а хотите купить виртуальные машины VMware в аренду - пожалуйста.

Несмотря на то, что в VMware vSphere Client диски виртуальных машин создаются уже выровненными относительно блоков системы хранения данных, многих пользователей платформы беспокоит, не выглядит ли их дисковая подсистема для ВМ таким образом:

Специально для таких пользователей, на сайте nickapedia.com появилась бесплатная утилита UBERAlign, которая позволяет найти виртуальные диски машин с невыровненными блоками и выровнять их по любому смещению.

Но самое интересное, что утилита UBERAlign работает еще и как средство, позволяющее уменьшать размер виртуальных дисков ВМ с "тонкими" дисками (thin provisioning), возвращая дисковое пространство за счет удаленных, но не вычищенных блоков.

Скачать UBERAlign можно по этой ссылке (а вот тут в формате виртуального модуля OVA), полный список возможностей утилиты можно найти тут (там еще несколько видеодемонстраций).

Многие пользователи VMware vSphere знают, что для кластера HA раньше была настройка das.failuredetectiontime - значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого времени срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины.

В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.

Теперь все работает следующим образом.

Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):

• Время T0 – обнаружение изоляции хоста (slave).
• T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
• T0+25 сек – Slave сам себя назначает мастером.
• T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Наступление изоляции хост-сервера ESXi, являющегося Master:

• T0 – обнаружение изоляции хоста (master).
• T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. Помним, да, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.

Ну и не забываем про заметку новые расширенные настройки и Isolation Responce.